The present invention relates to computer systems and, more particularly, to a method and system architecture for providing load sharing and/or high availability between virtual systems or applications running in a cluster of computers preferably in a security gateway between data networks Specifically, the applications residing in different computers of the cluster synchronize state parameters and policy between the applications.
There is a growing need within large enterprises to extend networks, applications, and corporate databases to business partners, and employees working off site and other guest users. At the same time, many administrators are starting to divide infrastructure among various departments and groups using virtual LANs (VLANs). Although VLAN technology is effective at functionally dividing these networks companies are still required to deploy separate security systems, e.g. firewall, virtual private networks (VPN), and intrusion prevention devices in front of each network segment to achieve comprehensive security The extension of the corporate networks and subdivision into separate VLANs results in an enterprise network which is expensive and carries a large management overhead.
In order to alleviate this problem Check Point™ (Check Point Software Technologies Ltd.) offers a product VPN-1® Virtual System Extension (VSX™) as a high-speed, multi-policy virtualized security solution designed for large-scale enterprise environments like data centers and campus networks. The VSX cluster is composed of multiple virtual security systems, each of which is a complete virtualized version of a VPN gateway.
Referring now to FIG. 1 (prior art) a simplified system block diagram of a prior art virtual system extension (VSX) cluster 10 is illustrated. Cluster 10 is composed of multiple computers or cluster members 101 attached in parallel as a cluster typically between Layer 2 switches 105. Layer 2 switches 105 interface with respective networks 111. Multiple virtual systems 103, e.g. firewall applications, are installed and ruining in each cluster member 101. In a typical application, cluster is installed and operated by a service provider and two cluster members 101a and 101b for instance are provided to an enterprise, with 101a active and 101b available for backup and failover if 101a fails. In the case of failover in this example, virtual systems 103 of cluster member 101b assume the tasks of virtual systems 103a of cluster member 101a. A drawback of this failover configuration is that if a failure occurs only in one virtual system 103 of cluster member 101a, for example as a result of a software error, or a hardware failure that affects only one virtual system 103 on the same cluster member, the other two operable virtual systems 103 of cluster member 101a are removed from service and not available until recovery from failures Furthermore, since a failover is not entirely risk free, there is a possibility of adverse consequences to sub-networks being serviced during failover by otherwise operable virtual systems 103.
There is thus a need for, and it would be highly advantageous to have a method of failover and load sharing between distinct virtual systems 103 of different cluster members 101, a method which maximizes efficient use of available resources in the cluster with high availability, scalability and simple reconfigurability.
Reference is now made to FIG. 2 (prior art) which illustrates a computer, for instance cluster member 101. Cluster member 101, includes a processor 201, a storage mechanism including a memory bus 207 to store information in memory 209 and a first and second interface 204 connecting to networks 111. Each interface 204 is operatively connected to processor 201 with a peripheral bus 203. Cluster member 101 further includes a data input mechanism 211, e.g. disk drive from a program storage device 213, e.g. optical disk. Data input mechanism 211 is operatively connected to processor 201 with a peripheral bus 203. Virtual systems 10) are installed in memory 209 and run by processor 201.
The term “virtual system” as used herein is an application installed in a computer, wherein the application performs a function and wherein the computer is not dedicated solely for the function or a single instance of the function. There is a least a potential for more than one “virtual system” to be installed on the computer, each “virtual system” using its own segment of memory attached to the computer; a “virtual system” functions identically or similarly to a non-virtual or dedicated system, e.g. non-virtual firewall system; “virtual systems” are individually configured and managed even if installed on the same computer 101; if a “virtual system” performs a function in a network, each “virtual system” installed may be connected to different network, either physical or virtual (VLAN); aid failure in one virtual system does not necessarily cause a failure in other virtual systems installed in the same computer 101. For further information regarding “virtual systems” and clusters thereof; reference is made to Check Point user information document (701171 March 2006) entitled “Check Point VSX Version NGX R60” included herein for all purposes as if fully set forth herein.
Hereinafter, the terms “virtual system” and “application” are used interchangeably in the context of parallel processes running under a single operating system in a computer.
The terms “application group” or “virtual system group” as used herein interchangeably, refers to multiple copies of the same application or process ruffling in different computers of a cluster.
The term “virtual system” should not be confused with the term “virtual machine”. A “virtual machine”, or “hardware virtual machine”, includes different execution environments on a single computer; each of which runs an operating system. The “virtual machine” (not related to the present invention) allows processes written for one operating system to be executed on a machine which runs a different operating system, or provide execution “sandboxes” which provide a greater level of isolation between processes but requires more resources than when running multiple processes on the same instance of an operating system.
The terms “monitoring” and “detecting” as used herein referring to a load or failure of a virtual system includes both automatic monitoring and detecting such as by a machine or manual monitoring and detection by a human being.
The term “memory” as used hereinafter refers to any type of computed memory or information storage device including volatile and non-volatile memory, random-access memory, magnetic memory, (e.g. hard disk) optical memory, (e.g. CD), EEPROM and flash memory.